\htmlhr
\chapterAndLabel{Troubleshooting, getting help, and contributing}{troubleshooting}

\begin{sloppypar}
The manual might already answer your question, so first please look for
your answer in the manual,
including this chapter and the FAQ (Chapter~\ref{faq}).
If you think you have found a bug in the Checker Framework,
please report it (see Section~\ref{reporting-bugs}).
For discussions of broad interest, you can use the mailing list,
\code{checker-framework-discuss@googlegroups.com}.
For archives and to subscribe, see \url{https://groups.google.com/forum/#!forum/checker-framework-discuss}.
If you want to help out, you can give feedback (including on the
documentation), choose a bug and fix it (start with those labeled
\href{https://github.com/typetools/checker-framework/issues?q=is\%3Aissue+is\%3Aopen+label\%3A\%22good+first+issue%22}{``good
first
issue''}),
or select a
project from the ideas list at
\url{https://checkerframework.org/manual/new-contributor-projects.html}.
\end{sloppypar}


\sectionAndLabel{Common problems and solutions}{common-problems}

\begin{itemize}
\item
To verify that you are using the compiler you think you are, you can add
\code{-version} to the command line.  For instance, instead of running
\code{javac -g MyFile.java}, you can run \code{javac \underline{-version} -g
  MyFile.java}.  Then, javac will print out its version number in addition
to doing its normal processing.  Note that if you are running under Java 8,
\<\$CHECKERFRAMEWORK/bin/javac -version> prints ``javac (version info
not available)'' because it uses the Error Prone compiler which does not
provide version information.

\end{itemize}


\subsectionAndLabel{Unable to compile the Checker Framework}{common-problems-compiling}

If you get the following error while compiling the Checker Framework itself:

%BEGIN LATEX
\begin{smaller}
%END LATEX
\begin{Verbatim}
checker-framework/stubparser/dist/stubparser.jar(org/checkerframework/stubparser/ast/CompilationUnit.class):
warning: [classfile] Signature attribute introduced in version 49.0 class files is ignored in version 46.0 class files
\end{Verbatim}
%BEGIN LATEX
\end{smaller}
%END LATEX

\noindent
and you have used Eclipse to compile the Checker Framework, then probably
you are using a very old version of Eclipse.  (If you
install Eclipse from the Ubuntu 16.04 repository, you get Eclipse version
3.8.  Ubuntu 16.04 was released in April 2016, and Eclipse 3.8 was released
in June 2012, with subsequent major releases in June 2013, June 2014, and
June 2015.)
Install the latest version of Eclipse and use it instead.


\subsectionAndLabel{Unable to run the checker, or checker crashes}{common-problems-running}

If you are unable to run the checker, or if the checker or the compiler
terminates with an error, then the problem may be a problem with your environment.
(If the checker or the compiler crashes, that is a bug in the Checker
Framework; please report it.  See Section~\ref{reporting-bugs}.)
This section describes some possible problems and solutions.

\begin{itemize}
\item
  \label{no-such-field-error-release}
  An error that includes \<java.lang.NoSuchFieldError: RELEASE"> means that
  you are not using the correct compiler (you are not using a Java 9+ compiler).

\item
If you get the error

%BEGIN LATEX
\begin{smaller}
%END LATEX
\begin{Verbatim}
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for com.sun.source.tree.Tree not found
\end{Verbatim}
%BEGIN LATEX
\end{smaller}
%END LATEX

\noindent
then you are using the source installation and file \code{tools.jar} is not
on your classpath.  See the installation instructions
(Section~\ref{installation}).

\item
If you get an error like one of the following,

%BEGIN LATEX
\begin{smaller}
%END LATEX
\begin{Verbatim}
...\build.xml:59: Error running ${env.CHECKERFRAMEWORK}\checker\bin\javac.bat compiler
\end{Verbatim}

\begin{Verbatim}
.../bin/javac: Command not found
\end{Verbatim}

\begin{Verbatim}
error: Annotation processor 'org.checkerframework.checker.signedness.SignednessChecker' not found
\end{Verbatim}
%BEGIN LATEX
\end{smaller}
%END LATEX

\noindent
then the problem may be that you have not set the \code{CHECKERFRAMEWORK} environment
variable, as described in Section~\ref{javac-wrapper}.  Or, maybe
you made it a user variable instead of a system variable.

\item
If you get one of these errors:

\begin{alltt}
The hierarchy of the type \emph{ClassName} is inconsistent

The type com.sun.source.util.AbstractTypeProcessor cannot be resolved.
  It is indirectly referenced from required .class files
\end{alltt}

\begin{sloppypar}
\noindent
then you are likely \textbf{not} using the Checker Framework compiler.  Use
either \code{\$CHECKERFRAMEWORK/checker/bin/javac} or one of the alternatives
described in Section~\ref{javac-wrapper}.
\end{sloppypar}

\item
If you get the error

\begin{Verbatim}
  java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy
\end{Verbatim}

\noindent
% I'm not 100% sure of the following explanation and solution.
then an annotation is not present at run time that was present at compile
time.  For example, maybe when you compiled the code, the \<@Nullable>
annotation was available, but it was not available at run time.

\item
If you get an error that contains lines like these:

\begin{Verbatim}
Caused by: java.util.zip.ZipException: error in opening zip file
    at java.util.zip.ZipFile.open(Native Method)
    at java.util.zip.ZipFile.<init>(ZipFile.java:131)
\end{Verbatim}

\noindent
then one possibility is that you have installed the Checker Framework in a
directory that contains special characters that Java's ZipFile
implementation cannot handle.  For instance, if the directory name contains
``\<+>'', then Java 1.6 throws a ZipException, and Java 1.7 throws a
FileNotFoundException and prints out the directory name with ``\<+>''
replaced by blanks.

\item
The Checker Framework sometimes runs out of memory when processing very
large Java files, or files with very large methods.

If you get an error such as
\begin{Verbatim}
error: SourceChecker.typeProcess: unexpected Throwable (OutOfMemoryError) while processing ...
  ; message: GC overhead limit exceeded
\end{Verbatim}

\noindent
(all on one line),
then either give the JVM more memory when running the Checker Framework, or
split your files and methods into smaller ones, or both.

\item
% Error Prone 2.5.0 was released in January 2021
Versions of \href{https://errorprone.info/}{Error Prone} before 2.4.0 are
incompatible with the Checker Framework.  (More precisely, each version of
Error Prone before 2.4.0 is compatible with only one specific version of
the Checker Framework.)  Those versions of Error Prone
use outdated versions of the Checker Framework's dataflow analysis
library, each of which is compatible with only one version of the Checker Framework.

If you wish to use both Error Prone and the Checker Framework, then use
Error Prone version 2.4.0 or later.
If you cannot upgrade to Error Prone 2.4.0 or later, there is a way to
still use both tools.  The
\ahreforurl{https://github.com/kelloggm/checkerframework-gradle-plugin\#incompatibility-with-error-prone}{Gradle
  plugin documentation} shows how to do so if you use the Gradle build
system.

\item
% NullAway 0.9.2 was released in July 2021.
Versions 0.9.0 and 0.9.1 of
\href{https://github.com/uber/NullAway}{NullAway} are compatible
only with Checker Framework version 3.6.0 through 3.8.0.  Those versions of
NullAway use version 3.6.0 of the Checker Framework's dataflow analysis
library without shading it.  As of version 0.9.2, NullAway uses a shaded version of
the library, so this conflict no longer exists.
If you want to use a version of the Checker Framework newer than 3.8.0 with
NullAway in the same build, then use NullAway 0.9.2 or later.

\end{itemize}


\subsectionAndLabel{Unexpected warnings not related to type-checking}{common-problems-non-typechecking}

This section gives solutions for some warning messages that are not related
to type errors in your code.

\begin{itemize}

\item
If you get an error like the following

\begin{Verbatim}
error: scoping construct for static nested type cannot be annotated
error: scoping construct cannot be annotated with type-use annotation
\end{Verbatim}

\noindent
  then you have probably written something like one of the following:
\begin{description}
\item[\<@Nullable java.util.List>]
The correct Java syntax to write an annotation on a fully-qualified type
name is to put the annotation on the simple name part, as in
\<java.util.@Nullable List>.  But, it's usually
better to add \<import java.util.List> to your source file, so that you can
just write \<@Nullable List>.
\item[\<@Nullable Map.Entry>]  You must write \<Outer.@Nullable
StaticNestedClass> rather than \<@Nullable Outer.StaticNestedClass>.
Since a static nested class does not depend on its outer class, the
annotation on the outer class would have no effect and is forbidden.
\end{description}

Java 8 requires that a type qualifier be written directly on the type that
it qualifies, rather than on a scoping mechanism that assists in resolving
the name.  Examples of scoping mechanisms are package names and outer
classes of static nested classes.

The reason for the Java 8 syntax is to avoid syntactic irregularity.  When
writing a member nested class (also known as an inner class), it is
possible to write annotations on both the outer and the inner class:  \<@A1
Outer. @A2 Inner>.  Therefore, when writing a static nested class, the
annotations should go on the same place:  \<Outer. @A3 StaticNested> (rather
than \<@ConfusingAnnotation Outer.\ Nested> where
\<@ConfusingAnnotation> applies to \<Outer> if \<Nested> is a member class
and applies to \<Nested> if \<Nested> is a static class).  It's not legal
to write an annotation on the outer class of a static nested class, because
neither annotations nor instantiations of the outer class affect the static
nested class.

Similar arguments apply when annotating \<pakkage.Outer.Nested>.

\item
An ``error: package ... does not exist'' or ``error: cannot find symbol''
about classes in your own project or its dependencies means that you have
left your own project or its dependencies off the classpath when you
invoked the compiler.

\end{itemize}


\subsectionAndLabel{Unexpected type-checking results}{common-problems-typechecking}

This section describes possible problems that can lead the type-checker to
give unexpected results.


\begin{itemize}
\item
  If the Checker Framework is unable to verify a property that you know is
  true, then you should formulate a proof about why the property is true.
  Your proof depends on some set of facts about the program and its
  operation.  State them completely; for example, don't write ``the field
  \<f> cannot be null when execution reaches line 22'', but justify
  \emph{why} the field cannot be null.

  Once you have written down your proof, translate each fact into a Java
  annotation.

  If you are unable to express some aspect of your proof as an annotation,
  then the type system is not capable of reproducing your proof.  You might
  need to find a different proof, or extend the type system to be more
  expressive, or suppress the warning.

  If you are able to express your entire proof as annotations, then look at
  the Checker Framework error messages.
  \begin{itemize}
  \item
    Perhaps your proof was incomplete or incorrect.  Your proof might
    depend on some fact you didn't write down, such as ``method
    \<m> has no side effects.''  In this case, you should revise your proof
    and add more annotations to your Java code.
  \item
    Perhaps your proof is incorrect, and the errors indicate where.
  \item
    Perhaps there is a bug in the type-checker.  In this case,
    you should report it to the maintainers, giving your proof and explaining
    why the type-checker should be able to make the same inferences that you did.
  \end{itemize}

  Recall that the Checker Framework does modular verification,
  one procedure at a time; it observes the specifications, but not the
  implementations, of other methods.

  Also see Section~\ref{handling-warnings}, which explains this same
  methodology in different words.

\item
If a checker seems to be ignoring the annotation on a method, then it is
possible that the checker is reading the method's signature from its
\code{.class} file, but the \code{.class} file was not created by a Java 8
or later compiler.
You can check whether the annotations actually appear in the
\code{.class} file by using the \code{javap} tool.

If the annotations do not appear in the \code{.class} file, here are two
ways to solve the problem:
\begin{itemize}
\item
  Re-compile the method's class with the Checker Framework compiler.  This will
  ensure that the type annotations are written to the class file, even if
  no type-checking happens during that execution.
\item
  Pass the method's file explicitly on the command line when type-checking,
  so that the compiler reads its source code instead of its \code{.class}
  file.
\end{itemize}

\item
If a checker issues a warning about a property that it accepted (or that
was checked) on a previous line, then probably there was a side-effecting
method call in between that could invalidate the property.  For example, in
this code:

\begin{Verbatim}
if (currentOutgoing != null && !message.isCompleted()) {
    currentOutgoing.continueBuffering(message);
}
\end{Verbatim}

\noindent
the Nullness Checker will issue a warning on the second line:
\begin{Verbatim}
warning: [dereference.of.nullable] dereference of possibly-null reference currentOutgoing
    currentOutgoing.continueBuffering(message);
    ^
\end{Verbatim}

If \<currentOutgoing> is a field rather than a local variable, and
\<isCompleted()> is not a pure method, then a null pointer
dereference can occur at the given location, because \<isCompleted()> might set
the field \<currentOutgoing> to \<null>.

If you want to communicate that
\<isCompleted()> does not set the field \<currentOutgoing> to \<null>, you can use
\<\refqualclass{dataflow/qual}{Pure}>,
\<\refqualclass{dataflow/qual}{SideEffectFree}>,
or \<\refqualclass{checker/nullness/qual}{EnsuresNonNull}> on the
declaration of \<isCompleted()>; see Sections~\ref{type-refinement-purity}
and~\ref{nullness-method-annotations}.


\item
If a checker issues a type-checking error for a call that the library's
documentation states is correct, then maybe that library method has not yet
been annotated, so default annotations are being used.

To solve the problem, add the missing annotations to the library (see
Chapter~\ref{annotating-libraries}).  The
annotations might appear in stub files (which appear
in an \code{.astub} file together with the checker's source code)
or in the form of annotated libraries (which appear
in \url{https://github.com/typetools/}).

\item
If the compiler reports that it cannot find a method from the JDK or
another external library, then maybe the stub file for that class
is incomplete.

To solve the problem, add the missing annotations to the library, as
described in the previous item.

The error might take one of these forms:

\begin{Verbatim}
method sleep in class Thread cannot be applied to given types
cannot find symbol: constructor StringBuffer(StringBuffer)
\end{Verbatim}

\item
If you get an error related to a bounded type parameter and a literal such
as \<null>, the problem may be missing defaulting.  Here is an example:

\begin{Verbatim}
mypackage/MyClass.java:2044: warning: incompatible types in assignment.
      T retval = null;
                 ^
  found   : null
  required: T extends @MyQualifier Object
\end{Verbatim}

\noindent
A value that can be assigned to a variable of type \<T extends @MyQualifier
Object> only if that value is of the bottom type, since the bottom type is
the only one that is a subtype of every subtype of \<T extends @MyQualifier
Object>.  The value \<null> satisfies this for the Java type system, and it
must be made to satisfy it for the pluggable type system as well.  The
typical way to address this is to call \<addStandardLiteralQualifiers> on the \<LiteralTreeAnnotator>.

\item
An error such as

\begin{Verbatim}
MyFile.java:123: error: incompatible types in argument.
                        myModel.addElement("Scanning directories...");
                                           ^
  found   : String
  required: ? extends Object
\end{Verbatim}

\noindent
may stem from use of raw types.  (``\<String>'' might be a different type
and might have type annotations.)  If your declaration was

\begin{Verbatim}
  DefaultListModel myModel;
\end{Verbatim}

\noindent
then it should be
\begin{Verbatim}
  DefaultListModel<String> myModel;
\end{Verbatim}

Running the regular Java compiler with the \<-Xlint:unchecked> command-line
option will help you to find and fix problems such as raw types.


\item
The error

\begin{Verbatim}
error: annotation type not applicable to this kind of declaration
    ... List<@NonNull String> ...
\end{Verbatim}

\noindent
indicates that you are using a definition of \<@NonNull> that is a
declaration annotation, which cannot be used in that syntactic location.
For example, many legacy annotations such as those listed in
Figures~\ref{fig-nullness-refactoring-nonnull} and \ref{fig-nullness-refactoring-nullable}
are declaration annotations.  You can
fix the problem by instead using a definition of \<@NonNull> that is a type
annotation, such as the Checker Framework's annotations; often this only
requires changing an \<import> statement.


\item
If Eclipse gives the warning

\begin{Verbatim}
The annotation @NonNull is disallowed for this location
\end{Verbatim}

\noindent
then you have the wrong version of the \<org.eclipse.jdt.annotation>
classes.  Eclipse includes two incompatible versions of these annotations.
You want the one with a name like
\<org.eclipse.jdt.annotation\_2.0.0.....jar>, which you can find in the
\<plugins> subdirectory under the Eclipse installation directory.
Add this .jar file to your build path.


\item
When one formal parameter's annotation references another formal
parameter's name, as in this constructor:

\begin{smaller}
\begin{Verbatim}
public String(char value[], @IndexFor("value") int offset, @IndexOrHigh("value") int count) { ... }
\end{Verbatim}
\end{smaller}

\noindent
you will get an error such as

\begin{smaller}
\begin{Verbatim}[]
[expression.unparsable] Expression in dependent type annotation invalid:
Use "#1" rather than "value"
\end{Verbatim}
\end{smaller}

Section~\ref{java-expressions-as-arguments} explains that you need to use
a different syntax to refer to a formal parameter:

\begin{smaller}
\begin{Verbatim}
public String(char value[], @IndexFor("#1") int offset, @IndexOrHigh("#1") int count) { ... }
\end{Verbatim}
\end{smaller}


\item
\label{false-positive-in-dead-code}
  The Checker Framework can issue false positive warnings in dead code.  An
  example is

\begin{smaller}
\begin{Verbatim}
  void m() {
    String t = "";
    t.toString();
    try {
    } catch (Throwable e) {
        t.toString(); // Nullness Checker issues spurious (dereference.of.nullable)
    }
\end{Verbatim}
\end{smaller}

\item
  If the Checker Framework issues an error or warning that you cannot
  reproduce using a smaller test case, then try running the Checker
  Framework with the \<-AatfDoNotCache> command-line argument.  If the
  Checker Framework behaves differently with and without that command-line
  argument, then there is a bug related to its internal caches.  Please
  report that bug at
  \url{https://github.com/typetools/checker-framework/issues}.

\end{itemize}


\subsectionAndLabel{Unexpected compilation output when running javac without a pluggable type-checker}{common-problems-running-javac}

A message of the form

\begin{Verbatim}
  error: annotation values must be of the form 'name=value'
        @LTLengthOf("firstName", "lastName") int index;
                    ^
\end{Verbatim}

\noindent
is caused by incorrect Java syntax.  When you supply a set of multiple
values as an annotation argument, you need to put curly braces around them:

\begin{Verbatim}
        @LTLengthOf({"firstName", "lastName"}) int index;
\end{Verbatim}


\sectionAndLabel{How to report problems (bug reporting)}{reporting-bugs}

If you have a problem with any checker, or with the Checker Framework,
please file a bug at
\url{https://github.com/typetools/checker-framework/issues}.
(First, check whether there is an existing bug report for that issue.)
If the problem is with an incorrect or missing annotation on a library,
including the JDK, see Section~\ref{reporting-bugs-annotated-libraries}.
You can also use the issue tracker to make suggestions and feature
requests.  We also welcome pull requests with annotated libraries, bug
fixes, new features, new checkers, and other improvements.

Please ensure that your bug report is clear and that it is complete.
Otherwise, we may be unable to understand it or to reproduce it, either of
which would prevent us from helping you.  Your bug report should include at
least the following 4 parts: commands, inputs, outputs, and expectation.

% If you update this, also update ../../.github/ISSUE_TEMPLATE
\begin{description}
\item[Commands]
  Provide one or more commands that can be pasted into a command shell to
  reproduce the problem.

  In the simplest case, you will provide one command of
  the form \<javac -processor ... MyFile.java>.  In more complex cases, it
  might be a set of commands clone a repository, check out a branch, and
  run a build command.  Include commands to install software and set
  environment variables if necessary.

  If you encountered the problem in an IDE, reproduce it from the command
  line; if you cannot, report the bug to the IDE integration.
  If you encountered the problem when using a build system, it is most
  useful to the Checker Framework developers if you provide a single
  \<javac> command rather than a build file.

  It can be helpful to add \\
  \code{-version -Aversion -AprintGitProperties -verbose -AprintVerboseGenerics} \\
  to the javac options.  This causes the
  compiler to output debugging information, including its version number.

\item[Inputs]
  Include all files that are necessary to reproduce the problem.  This
  includes every file that is used by any of the commands you reported, and
  possibly other files as well.  This is not necessary if the commands you
  provided obtain the code that is type-checked.

  If you cannot share your code, create a new, small test case.  (A small
  test case is helpful even if your code is not secret!)  If the Checker
  Framework crashed, the progress tracing options
  (Section~\ref{creating-debugging-options-progress}) can be helpful in
  determining which file the Checker Framework was processing when it
  crashed.

  \emph{Minimization:}
  If your command invokes a build system such as Gradle or Maven, it can be
  helpful to the maintainers if you are able to reduce it to a single
  \<javac> invocation on a single file.
  This also rules out the possibility that the problem is with the build system
  integration rather than the checker itself.
  If you use an invasive
  annotation processor such as Lombok, then try to reproduce the problem
  without it --- this will indicate whether the problem is in the Checker
  Framework proper or in its interaction with Lombok.

\item[Output]
  Indicate exactly what the result was by attaching a file or using
  cut-and-paste from your command shell.  Don't merely describe it in
  words, don't use a screenshot, and don't provide just part of the output.

\item[Expectation]
  If the problem is not a crash, then
  indicate what you expected the result to be, since a bug is a difference
  between desired and actual outcomes.  Also, please indicate \textbf{why}
  you expected that result --- explaining your reasoning can reveal
  how your reasoning is different than the checker's and which
  one is wrong.  Remember that the checker reasons modularly and
  intraprocedurally:  it examines one method at a time, using only the
  method signatures of other methods.

  It can also be helpful to indicate what you have already done to try to
  understand the problem.  Did you do any additional experiments?  What
  parts of the manual did you read, and what else did you search for in the
  manual?  Without this information, the maintainers may give you redundant
  suggestions or may waste time re-doing work you have already done.
\end{description}

% A particularly useful format for a test case is as a new file, or a diff to
% an existing file, for the existing Checker Framework test suite.  For
% instance, for the Nullness
% Checker, see directory \<checker-framework/checker/tests/nullness/>.
% But, please report your bug even if you do not report it in this format.

When reporting bugs, please focus on realistic scenarios and well-written
code.  We are sure that you can make up artificial code that stymies the
type-checker!  Those aren't a good use of your time to report nor the
maintainers' time to evaluate and fix.


\subsectionAndLabel{Problems with annotated libraries}{reporting-bugs-annotated-libraries}

If a checker reports a warning because a library contains \emph{incorrect} annotations,
then please open a pull request that adds the annotations.  If the
library's maintainers have added annotations, make a pull request to them.
If the Checker Framework maintainers have added annotations,
you can find the annotated source in \url{https://github.com/typetools/}.

If a checker reports a warning because a library is \emph{not
annotated}, please do not open a GitHub issue.
Instead, we appreciate pull requests to help us improve the annotations.
Alternatively or in the interim, you can use stub files as described in
Section~\ref{stub}.

For either approach, please see \chapterpageref{annotating-libraries} for
tips about writing library annotations.

Thanks for your contribution to the annotated libraries!


\sectionAndLabel{Building from source}{build-source}

The Checker Framework release (Section~\ref{installation}) contains
everything that most users need, both to use the distributed checkers and
to write your own checkers.  This section describes how to compile its
binaries from source.  You will be using the latest development version of
the Checker Framework, rather than an official release.

% Doing
% so permits you to examine and modify the implementation of the distributed
% checkers and of the checker framework.  It may also help you to debug
% problems more effectively.

The Checker Framework runs under any JDK version 8 or later.
However, you must build the Checker Framework under JDK 11 or later.


\subsectionAndLabel{Install prerequisites}{building-prerequisites}

You need to install several packages in order to build the Checker
Framework.
Follow the instructions for your operating system.
If your OS is not listed, adapt the instructions for an existing OS;
for example, other Linux distributions will be similar to Ubuntu.

% Why is this necessary?  What goes wrong if it is not set?  Can I avoid
% the need to set it?  It's used for:
%  * the location of tools.jar, below.
%  * the default location of CTSYM, in checker/jdk/Makefile.
Put the setting of the \<JAVA\_HOME> environment variable in a startup file
such as \<.bash\_profile> or \<.bashrc>, if \<JAVA\_HOME> is not already
set appropriately.  It must be the location of your JDK
installation (not the JRE installation).
You may need to log out and log back in for the setting to take effect.

\begin{description}
\item[Ubuntu]
  Run the following commands, which should be the same as those in
  \<checker/bin-devel/Dockerfile-ubuntu-jdk\emph{XX}-plus>, where \emph{XX}
  is a JDK version such as 8, 11, 17, 21, 25, etc.:

(This list should be the same as in
\<checker/bin-devel/Dockerfile-ubuntu-jdk25-plus>; if your build fails
because it is missing a package, try the commands there and report a bug
in this manual.)

% Keep this in sync with ../../checker/bin-devel/Dockerfile-ubuntu-jdk25-plus
% ... but before diffing with that, diff with
%   ../../checker/bin-devel/Dockerfile-contents-ubuntu-base.m4
%   ../../checker/bin-devel/Dockerfile-contents-ubuntu-plus.m4

\begin{Verbatim}
sudo apt -qqy update
# Dependencies for building and running the Checker Framework.
sudo apt -qqy install \
  ant \
  cpp \
  git \
  jq \
  jtreg7 \
  libcurl3-gnutls \
  make \
  maven \
  python3-requests \
  python3-setuptools \
  unzip \
  wget
# Dependencies for developing the Checker Framework.
apt -qqy install \
  autoconf \
  devscripts \
  dia \
  graphviz \
  hevea \
  imagemagick \
  junit \
  latexmk \
  librsvg2-bin \
  libasound2-dev libcups2-dev libfontconfig1-dev \
  libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev \
  pdf2svg \
  rsync \
  shellcheck \
  shfmt \
  texlive-font-utils \
  texlive-fonts-recommended \
  texlive-latex-base \
  texlive-latex-extra \
  texlive-latex-recommended

# Install uv (manages Python dependencies).
curl -LsSf https://astral.sh/uv/install.sh | sh
export PATH=$USER/.local/bin:$PATH

# Install markdownlint.
sudo apt -y install \
  npm
sudo npm install markdownlint-cli2 --global

# Install the JDK.
sudo apt -qqy install \
  openjdk-25-jdk \
&& update-java-alternatives --set java-1.25.0-openjdk-amd64
export JAVA25_HOME=/usr/lib/jvm/java-25-openjdk-amd64
\end{Verbatim}


  You may have to answer questions about which time zone your computer is in.

In a startup file, write:
% Can someone give a simpler command?
% Command taken from:
%   https://github.com/typetools/checker-framework/blob/master/checker/bin-devel/clone-related.sh#L19
%BEGIN LATEX
\begin{smaller}
%END LATEX
\begin{Verbatim}
  export JAVA_HOME=${JAVA_HOME:-$(dirname "$(dirname "$(readlink -f "$(which javac)")")")}
\end{Verbatim}
%BEGIN LATEX
\end{smaller}
%END LATEX

\item[macOS]
  If you employ \href{https://brew.sh}{homebrew} to install packages, run
  the following commands:

\begin{Verbatim}
brew update
brew install git graphviz ant hevea maven librsvg unzip make
brew install --cask temurin17
brew install --cask mactex
\end{Verbatim}

Note: Running \<brew install --cask temurin17> is only necessary if you do not
already have a JDK that is compatible with the Checker Framework installed.

Make a \<latex> directory and copy \<hevea.sty> file into it.
(\url{https://hevea.inria.fr/} gives the current version number.)

\begin{Verbatim}
mkdir -p $HOME/Library/texmf/tex/latex
cp -p /opt/homebrew/Cellar/hevea/2.36/lib/hevea/hevea.sty $HOME/Library/texmf/tex/latex/
\end{Verbatim}

Note: If copy permission is denied, try \<sudo>.

If \<echo \$JAVA\_HOME> outputs nothing (that is, if the \<JAVA\_HOME>
environment variable is not set), then write the following
in a startup file:

\begin{Verbatim}
export JAVA_HOME=$(/usr/libexec/java_home -v XX)
\end{Verbatim}
or
\begin{Verbatim}
export JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-XX.jdk/Contents/Home/
\end{Verbatim}

In the command, \emph{XX} is a JDK version such as 17, 21, 24, etc.

\item[Windows]
  To build on Windows 10 or later,
  run \<bash> to obtain a version of
  Ubuntu (provided by the Windows Subsystem for Linux) and follow the Ubuntu
  instructions.

% To build on other versions of Windows,
% here is an \emph{incomplete} list of needed prerequisites:
% \begin{itemize}
% \item
%   Install MSYS to obtain the \<cp> and \<make> commands.
% \end{itemize}

\end{description}


\subsectionAndLabel{Obtain the source}{building-obtain-source}

Obtain the latest source code from the version control repository:

\begin{Verbatim}
git clone https://github.com/typetools/checker-framework.git checker-framework
export CHECKERFRAMEWORK=$(pwd)/checker-framework
\end{Verbatim}
% $ to unconfuse Emacs LaTeX mode

You might want to add an \<export CHECKERFRAMEWORK=...> line to your
\<.bashrc> file.


\subsectionAndLabel{Build the Checker Framework}{building}

% Building (compiling) the checkers and framework from source creates the
% \code{checker.jar} file.  A pre-compiled \code{checker.jar} is included
% in the distribution, so building it is optional.  It is mostly useful for
% people who are developing compiler plug-ins (type-checkers).  If you only
% want to \emph{use} the compiler and existing plug-ins, it is sufficient to
% use the pre-compiled version.

\begin{enumerate}

\item
As with any Gradle project, run \code{./gradlew assemble} to build the Checker Framework:

\begin{Verbatim}
  cd $CHECKERFRAMEWORK
  ./gradlew assemble
\end{Verbatim}
% $ to unconfuse Emacs LaTeX mode

\noindent
Your antivirus program (e.g., Windows Security Virus \& threat protection)
might make the build run very slowly, or might make it seem to stall.  Just
give it time.

If compilation fails, but you have not made any changes, then perhaps one
of the supporting repositories is in an inconsistent state; see
Section~\ref{building-related-repositories}.

\item
Once it is built, you may wish to put the Checker Framework's \<javac>
even earlier in your \<PATH>:

\begin{Verbatim}
export PATH=$CHECKERFRAMEWORK/checker/bin:${PATH}
\end{Verbatim}

The Checker Framework's \code{javac} ensures that all required
libraries are on your classpath and boot classpath, but is otherwise
identical to the javac Java compiler.

Putting the Checker Framework's \<javac> earlier in your \<PATH> will
ensure that the Checker Framework's version is used.

\item
If you wish to use Maven or Gradle, publish the Checker Framework artifacts to a local Maven repository, run
\code{./gradlew publishToMavenLocal}
\begin{Verbatim}
  cd $CHECKERFRAMEWORK
  ./gradlew publishToMavenLocal
\end{Verbatim}
Then use the Maven or Gradle instructions, but modify the version number for the Checker Framework artifacts.
Use the version number that is output when you run \code{./gradlew version}.

\item Test that everything works:

  \begin{itemize}

  \item Run \code{./gradlew allTests}:
\begin{Verbatim}
  cd $CHECKERFRAMEWORK
  ./gradlew allTests
\end{Verbatim}
% $ to unconfuse Emacs LaTeX mode

  \item Run the Nullness Checker examples (see
    Section~\refwithpage{nullness-example}).

  \end{itemize}

\end{enumerate}


\subsectionAndLabel{Build the Checker Framework Manual (this document)}{building-manual}

\begin{enumerate}
\item
Install needed packages; see Section~\ref{building-prerequisites} for
instructions.

\item
Run \code{make} in the \code{docs/manual} directory to build both the PDF and HTML versions of the manual.
\end{enumerate}


\subsectionAndLabel{Code style, IDE configuration, pull requests, etc.}{building-developer-manual}

Please see the
\href{https://checkerframework.org/manual/developer-manual.html}{Checker Framework Developer Manual}.


\subsectionAndLabel{Enable continuous integration builds}{building-ci}

We strongly recommend that you enable continuous integration (CI) builds on
your fork of the projects, so that you learn quickly about errors.  See the
\href{https://checkerframework.org/manual/developer-manual.html\#ci}{CI
  instructions} in the Checker Framework Developer Manual.


\subsubsectionAndLabel{Debugging continuous integration builds}{building-ci-debug}

If a continuous integration job is failing, you can reproduce the problem locally.
The CI jobs all run within Docker containers.
Install Docker on your local computer, then perform commands like the
following to get a shell within Docker:

\begin{Verbatim}
docker pull mdernst/cf-ubuntu-jdk21
docker run -it mdernst/cf-ubuntu-jdk21 /bin/bash
\end{Verbatim}

Then, you can run arbitrary commands, including those that appear in the
CI configuration files.  For example:

\begin{Verbatim}
git clone --filter=blob:none -b docker-ubuntu-24-10 https://github.com/mernst/checker-framework.git
cd checker-framework
export CHECKERFRAMEWORK=$(pwd)
alias javacheck='$CHECKERFRAMEWORK/checker/bin/javac'
export NO_WRITE_VERIFICATION_METADATA=true
checker/bin-devel/test-cftests-junit.sh
\end{Verbatim}


\subsectionAndLabel{Related repositories}{building-related-repositories}

Building the Checker Framework depends on other repositories, such as
\href{https://github.com/typetools/jdk/}{Annotated JDK}.
You need to have compatible versions of each.

After you \<git pull> in one of the repositories, you should do so in the
others as well.  The script \<checker/bin-devel/clone-related.sh> pulls all the
related repositories, so to build the latest development version of the
Checker Framework you can do

\begin{Verbatim}
cd $CHECKERFRAMEWORK
git pull
checker/bin-devel/clone-related.sh
\end{Verbatim}


\sectionAndLabel{Contributing}{contributing}

We welcome contributions and pull requests.  Section~\ref{build-source}
tells you how to set up your development environment to compile the Checker
Framework, and the
\href{https://checkerframework.org/manual/developer-manual.html}{Checker
  Framework Developer Manual} gives more information.

One good way to contribute is to give feedback about your use of the tool.
There is a list
of potential projects for new contributors at
\url{https://checkerframework.org/manual/new-contributor-projects.html}.
Or, you can fix a bug that
you have encountered during your use of the Checker Framework.


\subsectionAndLabel{Contributing fixes (creating a pull request)}{pull-request}

Please see the
\href{https://checkerframework.org/manual/developer-manual.html#pull-requests}{pull
  requests} section of the Checker Framework Developer Manual.
Thanks in advance for your contributions!

The easiest bugs to fix for a newcomer are
\href{https://github.com/typetools/checker-framework/issues?q=is\%3Aopen+is\%3Aissue+label\%3A\%22good+first+issue\%22}{labeled
  as ``good first issue''}.

Please do not spam the issue tracker with requests to assign an issue to
you.  If you want to contribute by fixing an issue, just open a pull
request that fixes it.  You can do that even if the issue is already
assigned to someone.

Please do not spam the issue tracker asking how to get started fixing a
bug.  If you have concrete questions, please ask them and we will be happy
to assist you.  If you don't know how to get started fixing a particular
bug, then you should contribute to the project in other ways.  Thanks!


\sectionAndLabel{Credits and changelog}{credits}

Differences from previous versions of the checkers and framework can be found
in the \code{docs/CHANGELOG.md} file.  This file is included in the
Checker Framework distribution and is also available on the web at
\myurl{https://checkerframework.org/CHANGELOG.md}.

Developers who have contributed code to the Checker Framework include
\input{contributors.tex}

In addition, too many users to list have provided valuable feedback, which
has improved the toolset's design and implementation.
Thanks for your help!


\sectionAndLabel{License}{license}

Two different licenses apply to different parts of the Checker Framework.
\begin{itemize}
\item
The Checker Framework itself is licensed under the GNU General Public License
(GPL), version 2, with the classpath exception.
This is the same license that OpenJDK is licensed
under.  Just as compiling your code with javac does not infect your code
with the GPL, type-checking your code with the Checker Framework does not
infect your code with the GPL\@.  Running the Checker Framework during
development has no effect on your intellectual property or licensing.

If you want to ship the Checker Framework as part of your product, then
your product may need to be licensed under the GPL\@.  Because of the
classpath exception, you can include parts of the Checker Framework in your
product, even if your product uses a different license.  For example,
Google's \href{https://github.com/google/error-prone}{Error Prone} and
Uber's \href{https://github.com/uber/NullAway}{NullAway} both use the
Checker Framework internally, but neither one is licensed under the GPL\@.

\item
The more permissive MIT License applies
to code that you might want to include in your own
program, such as the annotations and run-time utility classes.
\end{itemize}

\noindent
For details, see file
\href{https://raw.githubusercontent.com/typetools/checker-framework/master/LICENSE.txt}{\<LICENSE.txt>}.


\sectionAndLabel{Publications}{publications}

Here are some papers that use the Checker Framework;
for instance, they build a type-checker on top of the Checker Framework, or
their methodology depends on using the Checker Framework.
(It is not papers that merely cite the Checker Framework.)
This list is \emph{incomplete}; if you know of a paper that
is missing, please let us know so that we can add it.
Most educational use of the Checker Framework is never published, and most
commercial use of the Checker Framework is never discussed publicly.
Most of the papers are available for free online; do a web search on the
title.

\begin{itemize}
% To populate this list, use 3 searches for "checker framework" (because each one misses some papers):
% TODO: add searches for citations of some of my papers, such as our two main papers and also tool papers.

% https://dl.acm.org/action/doSearch?AllField=%22checker+framework%22&sortBy=Ppub_asc&expand=all
% https://scholar.google.com/scholar?q=%22checker+framework%22+or+checkerframework&hl=en&as_sdt=0%2C48&as_ylo=2013&as_yhi=2013
% https://www.semanticscholar.org/search?year%5B0%5D=2011&year%5B1%5D=2011&fos%5B0%5D=computer-science&q=%22checker%20framework%22&sort=relevance

% 2008
\item
  Practical pluggable types for Java (ISSTA 2008)~\cite{PapiACPE2008}
\item
  % Tool paper
  Building and using pluggable type systems with the Checker Framework
  (ECOOP 2008)~\cite{Ernst2008}

% 2009
\item
  Type-Based Object Immutability with Flexible Initialization (ECOOP
  2009)~\cite{HaackP2009}

% 2010
\item
  The nullness analyser of Julia (LPAR 2010)~\cite{Spoto10:LPAR}
\item
  Static checking of safety critical Java annotations (JTRES 2010)~\cite{TangPJ2010}
\item
  Ownership and immutability in generic Java (OOPSLA 2010)~\cite{ZibinPLAE2010}
\item
  Rethinking the economics of software engineering (FOSER 2010)~\cite{SchillerE2010}
\item
  Applying uniqueness to the Java language (Master's Thesis, 2010)~\cite{Harper2010}
\item
  TIFI+: A Type Checker for Object Immutability with Flexible
  Initialization (Diploma thesis, 2010)~\cite{Noack2010}


% 2011
\item
  Building and using pluggable type-checkers (ICSE 2011)~\cite{DietlDEMS2011}
\item
  Inference of field initialization (ICSE 2011)~\cite{SpotoE2011}
\item
  EnerJ: approximate data types for safe and general low-power computation
  (PLDI 2011)~\cite{SampsonDFGCG2011}
\item
  Tunable static inference for generic universe types (ECOOP 2011)~\cite{DietlEM2011}
\item
  Separating ownership topology and encapsulation with generic universe
  types (TOPLAS 2011)~\cite{DietlDM2011}
\item
  The design, implementation and evaluation of a pluggable type checker for
  thread-locality in Java (Master's Thesis, 2011)~\cite{Sherwany2011}
\item
  Towards Effective Inference and Checking of Ownership Types (IWACO 2011)~\cite{HuangM2011}
\item
  Static Dominance Inference (TOOLS 2011)~\cite{MilanovaV2011}
\item
  A Static Memory Safety Annotation System for Safety Critical Java (RTSS 2011)~\cite{TangPNV2011}

% 2012
\item
  Inference and checking of object ownership (ECOOP 2012)~\cite{HuangDME2012}
\item
  A type system for regular expressions (FTfJP 2012)~\cite{SpishakDE2012}
\item
  Verification games: making verification fun (FTfJF 2012)~\cite{DietlDEMWCPP2012}
\item
  Reim \& ReImInfer: checking and inference of reference immutability and
  method purity (OOPSLA 2012)~\cite{HuangMDE2012}
\item
  ReImInfer: method purity inference for Java (FSE 2012)~\cite{HuangM2012}
\item
  Inference and checking of context-sensitive pluggable types (FSE 2012)~\cite{MilanovaH2012}
\item
  Documenting Java database access with type annotations (WorldComp 2012)~\cite{Bergstein2012}

% 2013
\item
  Immutability (book chapter, 2013)~\cite{PotaninOZE2013}
\item
  JavaUI: Effects for controlling UI object access (ECOOP 2013)~\cite{GordonDEG2013}
\item
  Reified type parameters using Java annotations (GPCE 2013)~\cite{GerakiosBS2013}
\item
  Evaluating the Accuracy of Annotations in the Loci 3.0 Pluggable Type
  Checker (Master's Thesis, 2013)~\cite{Zaza2013}
\item
  Composing polymorphic information flow systems with reference
  immutability (FTfJP 2013)~\cite{MilanovaH2013}


% 2014
\item
  Type-based taint analysis for Java web applications (FASE 2014)~\cite{HuangDM2014}
\item
  A type system for format strings (ISSTA 2014)~\cite{WeitzKSE2014}
\item
  Collaborative verification of information flow for a high-assurance app
  store (CCS 2014)~\cite{ErnstJMDPRKBBHVW2014}
\item
  Cascade: A universal type qualifier inference tool (ICSE 2015)~\cite{VakilianPEJ2015}
\item
  An inference and checking framework for context-sensitive pluggable types
  (PhD thesis, 2014)~\cite{Huang2014}
\item
  CFL-reachability and context-sensitive integrity types (PPPJ 2014)~\cite{MilanovaHD2014}


% 2015
\item
  Static analysis of implicit control flow: resolving Java reflection and
  Android intents (ASE 2015)~\cite{BarrosJMVDdAE2015}
\item
  Scalable and Precise Taint Analysis for Android (ISSTA 2015)~\cite{HuangDMD2015}
\item
  A context-sensitive security type system for Java (Master's thesis, 2015)~\cite{Kaiser2015}


% 2016
\item
  Locking discipline inference and checking (ICSE 2016)~\cite{ErnstLMST2016}
\item
  Semantics for locking specifications (NFM 2016)~\cite{ErnstMMS2016}
\item
  JCrypt: Towards computation over encrypted data (PPPJ 2016)~\cite{DongMD2016:JCrypt}
\item
  Preventing signedness errors in numerical computations in Java (FSE
  2016)~\cite{Mackie2016}
\item
  Enforcing correct array indexes with a type system (FSE 2016)~\cite{Santino2016}
\item
  Gradual Pluggable Typing in Java (Master's Thesis, 2016)~\cite{Brotherston2016}
\item
  Security analysis of the IRMA app using SPARTA and fuzzing (Bachelor
  Thesis, 2016)~\cite{Brinker2016}
\item
  Static Analysis and Program Transformation for Secure Computation on the
  Cloud (ISSTA 2016 Doctoral Symposium)~\cite{DongMD2016:secure-cloud}
\item
  Towards using concurrent Java API correctly (ICECCS 2016)~\cite{LiuBSD2016}
\item
  Reflection-aware static analysis of Android apps (ASE 2016)~\cite{LiBOK2016}
\item
  A crowdsourcing game for formal software verification (Bachelor's thesis)~\cite{Irini2016}
\item
  Exploring Language Support for Immutability (ICSE 2016)~\cite{CoblenzSAMWS2016}


% 2017
\item
  Granullar: Gradual nullable types for {Java} (CC 2017)~\cite{BrotherstonDL2017}
\item
  Type checking for reliable APIs (WAPI 2017)~\cite{KechagiaS2017}
\item
  Glacier: transitive class immutability for Java (ICSE 2017)~\cite{CoblenzNAMS2017}
\item
  A General Pluggable Type Inference Framework and its use for Data-flow
  Analysis (Master's Thesis, 2017)~\cite{Li2017}
\item
  Null safety benchmarks for object initialization (ISP RAS, 2017)~\cite{Kogtenkov2017}
\item
  Static analysis and program transformation for secure computation on the
  cloud (PhD Thesis, 2017)~\cite{Dong2017}
\item
  Spartan Jester: end-to-end information flow control for hybrid Android
  applications (SPW 2017)~\cite{SextonCN2017}

% DARPA report: Static Program Analysis for Reliable, Trusted Apps

% 2018
\item
  Lightweight verification of array indexing (ISSTA 2018)~\cite{KelloggDME2018}
\item
  Safe Stream-based Programming with Refinement Types (ASE 2018)~\cite{SteinCSC2018}
\item
  Don't miss the end: Preventing unsafe end-of-file comparisons (NFM 2018)~\cite{ChenD2018}
\item
  Context sensitive typechecking and inference: ownership and immutability
  (Master's Thesis, 2018)~\cite{Ta2018}
\item
  Usable and Sound Static Analysis through its Integration into Automated
  and Interactive Workflows (Master's Thesis, 2018)~\cite{Valgma2018}
\item
  Pluggable properties for program understanding: Ontic type checking and
  inference (Master's Thesis, 2018)~\cite{Chen2018}
\item
  Definite reference mutability (ECOOP 2018)~\cite{Milanova2018}
\item
  Googletest to CUTE converter (Technical report, 2018)~\cite{GschwindV2018}

% Implementierung eines automatischen Refactorings zur Reduzierung von dupliziertem Quellcode
% https://elib.uni-stuttgart.de/handle/11682/10449

% 2019
\item
  NullAway: Practical type-based null safety for Java (ESEC/FSE 2019)~\cite{BanerjeeCS2019}
\item
  Compile-time detection of machine image sniping (ASE 2019)~\cite{Kellogg2019}
\item
  Type-Directed Bounding of Collections in Reactive Programs (VMCAI 2019)~\cite{LuCCT2019}
\item
  Scala with Explicit Nulls (Master's Thesis, 2019)~\cite{NietoRodriguez2019}
\item
  A machine-checked proof of security for AWS Key Management Service (CCS, 2019)~\cite{AlmeidaBBCCGPPST2019}

% 2020
\item
  Synthesis of assurance cases for software certification (ICSE NIER 2020)~\cite{BagheriKM2020}
\item
  Verifying object construction (ICSE 2020)~\cite{KelloggRSSE2020}
\item
  Precise inference of expressive units of measurement types (OOPSLA 2020)~\cite{XiangLD2020}
\item
  Rethinking safe consistency in distributed object-oriented programming
  (OOPSLA 2020)~\cite{KohlerEWMS2020}
\item
  Continuous compliance (ASE 2020)~\cite{KelloggSTE2020}
\item
  Light-weight verification of cryptographic API usage (Master's Thesis, 2020)~\cite{Xing2020}
\item
  Type checking and whole-program inference for value range analysis (Master's Thesis, 2020)~\cite{Xiang2020}
\item
  User-Centered Design of Principled Programming Languages (PhD thesis, 2020)~\cite{Coblenz2020}
\item
  Behavioural types for memory and method safety in a core object-oriented
  language (APLAS 2020)~\cite{BravettiFGHJKR2020}
\item
  Scala with Explicit Nulls (ECOOP 2020)~\cite{NietoZLCP2020}

% 2021
\item
  Property Types in {Java}: Combining Type Systems and Deductive Verification
  (Master's Thesis, 2021)~\cite{Lanzinger2021}
\item
  Interval Type Inference: Improvements and Evaluations
  (Master's Thesis, 2021)~\cite{Wang2021}
\item
  Coping with the reality: adding crucial features to a
  typestate-oriented language (Master's Thesis, 2021)~\cite{daLuzMotaM2021}
\item
  Java Typestate Checker (Coordination 2021)~\cite{MotaGR2021}
\item
  Ensuring correct cryptographic algorithm and provider usage at compile time
  (FTFjP 2021)~\cite{XingCD2021}
\item
  Scalability and Precision by Combining Expressive Type Systems and
  Deductive Verification (OOPSLA 2021)~\cite{LanzingerWUD2021}
\item
  Automatic Annotation of Confidential Data in Java Code (FPS 2021)~\cite{BastysBRS2021}

% 2022
\item
  Accumulation Analysis (ECOOP 2022)~\cite{KelloggSSE2022}
\item
  Lightweight Verification via Specialized Typecheckers (PhD thesis, 2022)~\cite{Kellogg2022}


\end{itemize}



% LocalWords:  jsr unsetting plugins langtools zipfile cp plugin Nullness txt
% LocalWords:  nullness classpath NonNull MyObject javac uref changelog MyEnum
% LocalWords:  subtyping containsKey proc classfiles SourceChecker javap jdk
% LocalWords:  MyFile buildfiles ClassName JRE java bootclasspath
%  LocalWords:  extJavac ZipFile AnoPrintErrorStack AprintAllQualifiers Jlint
%  LocalWords:  Telmo Correa Papi NoSuchFieldError ZipException Xlint A1
%  LocalWords:  FileNotFoundException MyQualifier ImplicitFor A2 A3 JDKs
%  LocalWords:  StaticNestedClass StaticNested ConfusingAnnotation pre yml
%%  LocalWords:  CHECKERFRAMEWORK currentOutgoing isCompleted ElementType
%%  LocalWords:  EnsuresNonNull devel javacutil stubparser rsvg Regex IGJ
%%  LocalWords:  JavaUI EnerJ App CCS ReIm ReImInfer Anatoly Kupriyanov ci
%%  LocalWords:  Asumu Takikawa Brotherston McArthur Luo Bayne Coblenz Lai
%%  LocalWords:  Barros Athaydes Ren Oblak Heule Steph Trask Stalnaker
%%  LocalWords:  toolset's typechecking LiteralKind reifiable plaintext
%%  LocalWords:  astub homebrew hevea allTests AatfDoNotCache Java''
%%  LocalWords:  compileJava typedefs LPAR Tunable OIGJ sudo wanted''
% LocalWords:  addStandardLiteralQualifiers AprintGitProperties checkers''
% LocalWords:  expressions'' strings'' access'' intents'' ownership''
% LocalWords:  Computation'' Store'' generics'' immutability'' purity''
% LocalWords:  comparison''
